These are notes from our evaluation of various language candidates for the xFOCE Gateway codebase.

	Java	C++	C
Determinism/RT performance	*	**	***	Java and C had similar performance in the timer test, but it was more straightforward to write simple working demonstration and tune performance in C than Java. In full system, concern is that Java would  not perform as well, and be more susceptible to third party code not optimized for embedded use. The nominal real time requirement is to support sampling (~16 services) at 5 Hz; the precise requirements aren't known, and new requirements may emerge to sample at high rates for predicitive/feed-forward elements that we can't anticipate today. The real time requirements aren't thought to be high, but they are not well defined. We should leave some performance head room for this, and C has an edge over Java, both in benchmarks and being geared towards efficient embedded performance
Strong data typing	***	**	*	All (three) languages are strongly typed, but (void) pointers present pitfalls for the uninitiated. Java has better compile time enforcement of data typing, which is a plus for the developer.
Memory Management	***	*	**	Java is garbage collected, though there is a performance cost. On an embedded system, care must be taken to avoid object creation, and it isn't always clear to users which practices will lead to heavy GC use. The GC mechanism is not exposed well (i.e. it is opaque). Though there are some tuning parameters, it is not straightforward to use them, especially for an inexperienced user. C/C++ must me explicitly managed, requiring skill and effort, but maybe ultimately more reliable. Rather than provide a false sense of security, it may be better for users to assume responsibility for memory managment. A framework can provide mechanisms to make this easier and more reliable. There is not concensus about which strategy is preferable In some initial load testing, determinacy problems (gaps of several seconds) that were initially thought to be caused by GC turned out to be related to file IO (possibly the underlying native file system implementation, which silently fails to support non-blocking IO to disk). It took a while to rule out GC and find the problem, making us consider and test our basic implementaiton strategy in a number of ways. We have not characterized the effects of GC on performance for our platform, but have questions about the level of skill and care needed to avoid GC problems.
Anticipated codebase size	?	?	?	We should keep the codebase as small as possible, but maintainable. It would probably be larger than OASIS, since it adds features and requirements (coordination of services, real time data access, user interface clients, metadata handling, etc.). Larger codebases with multiple developers would lead to using OO; generally OO also enables software reuse. On the other hand, the Linux kernel and many other projects are primarily C and have many developers. xFOCE implementers will likely have few developers, and the codebase is intended to be kept small enough for one developer to manage. Any of these languages would be OK from this perspective.
Easier to understand	?	?	?	Very subjective, very important but difficult to evaluate as a selection criteria
Easier to debug	**	*	***	OO initialization and execution paths can be hard to trace because of inheritance and polymorphism. C execution  is more linear, and is easier to trace. There are pretty good tools available for all of these languages, including IDEs, debuggers, profilers. The tools may be a little easier to assemble and use for Java, though they are somewhat less geared towards embedded systems.
Productivity	***	*	**	There are good productivity tools for any of the languages. Java compiler is much slower on the host platform for a given application, so the edit/compile/debug cycle is long on the host. There are cross compilation environments for any of these languages, though Java may be easier to install.  There are some nice profiling tools for both C and Java.
Requires users to understand language internals	**	*	***	Java exposes less of the language internals and has a lot of opaque libraries, so it isn't always clear where to turn when tackling performance problems. On the other hand, C/C++ can be pretty technical and require better understanding of the hardware, but provide more (and more explicit) knobs for adjusting performance.
Direct control of hardware	*	**	***	C is especially well suited to programming for embedded hardware (e.g. memory mapped IO, precision timers, interrupt handling)
Portability	**	*	***	C/C++ compilers more ubiquitous and of more consistent quality than JVMs for small embedded platforms. Java is intended to be cross platform (and is), but less so in the embedded space. There are many embedded platforms that don't support Java, especially in the low-power end of the processor ecosystem. There are however many ARM variants that can run Java thanks to the mobile device industry. But if users really have a need to port to a lower power processor, there are many more options with C language support, making it an easier technology pattern to follow.
Extensibility	***	*	**	The risk with OO languages are that we will build a framework that is too large and abstract, and that our users will probably do cut and paste extension anyway. A risk with C is that it can be more difficult to propagate changes affecting multiple modules in C if the codebase is not well designed.  OO languages have an extensibility advantage for disciplined software engineers and teams, but our users may benefit less from that, and our codebase may become bloated and abstract as a result.
Existing user base	?	?	?	The existing user base (population 2) is not statistially significant. They favor procedural (eFOCE) and graphical (cpFOCE) approaches; science users use a lot of Matlab, where they tend to use procedural methods Will hopefully get some more data on this as time goes by.
Licensing	?	?	?	No large advantage for any choice. Java is somewhat harder to integrated into a rootfs image using the openembedded tools. Because it can't be automatically downloaded by bitbake, I think it introduces some manual steps in the rootfs  build process.
Exportability exemplars	**	*	***	SIAM, OASIS, PUCK, FOCE; OASIS has more successful exports, and is of similar scope and scale to FOCE. cpFOCE used LabView, eFOCE uses Arduino Processing/Wiring language (not C++ bindings) Cawthron (OASIS) users expressed preference for C over Java
Verbosity/readability	***	**	*	Overall, It may take more lines of code to get the same job done in C than Java, though it depends on the job.
Application Domain	*	**	***	Some would assert that C is better for system and hardware code, Java/C++ better for application code. xFOCE is evenly distributed across the stack, but leans a little to the hardware side. The shore side is in the application domain (and can be decoupled through message passing architecture).
xFOCE code developers' preference	**	*	***	We are divided on this: one with a strong preference for an OO language (preferably Java), one for Java, three for C.
Likely implementer background	?	?	?	Electro-mechanical person w/ some software experience in a high level language (C, Java or similar) - we think. This is a difficult criteria to apply, because it is unknown and we have little past data to make inferences from.
Likely operator background	**	*	***	Familiar with Matlab, maybe Fortran, C. This is a difficult criteria to apply, yada yada...
Most taught In schools	?	?	?	for which curriculum (CS, ME, EE, Robotics)? Based on what data? Hard to measure and understand importance, so not a good criteria
Currency of language	**	*	***	Procedural programming and OO are both valid, contemporary approaches. Several sources say that that C is still more popular than Java. It is possible to write well organized, extensible code using either; we should select the approach that is most likely to make xfoce users successful based on business and technical criteria, even if it is different from what we are most familiar with. There was some question about the currency of C; we all agree that it is important to favor modern technologies, methods and practices as the foundations of xFOCE. It is difficult to determine what the most used language is. It is easy to find surveys based on search results; these indicate that C, Java and C++ would be the top three contenders. It is easy to find articles and blog posts with any answer you'd care to find. All could be appropriate choices for FOCE.
It is more likely that Java programmers would be familiar with C than vice versa	?	?	?	Many Java programmers learned C or another procedural language as their first programming language.
Other embedded applications at MBARI	**	*	***	Many embedded data collection systems us primarily e C/C++: Tiburon, OASIS, Dorado, PUCK, LRAUV, Autonomy, DataManager, Benthic Respirometer Many of the data systems use Java: SSDS, VARS, ODSS, FOCE GUI SIAM uses Java (a notable exception among embedded data collection system) ESP uses C/C++ and Ruby There are several projects that use LabView: MiniROV, Benthic ecology aquaria It may be useful to use Java clients and components for swFOCE on the shore to interface with xFOCE; a message passing architecture will decouple the gateway language choice from the data system.